home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19961006-19970104 / 000368_news@columbia.edu _Fri Dec 27 13:49:47 1996.msg < prev    next >
Internet Message Format  |  1996-12-31  |  5KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.8.3/8.8.3) with ESMTP id NAA04825 for <kermit.misc@watsun.cc.columbia.edu>; Fri, 27 Dec 1996 13:49:47 -0500 (EST)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.8.3/8.8.3) id NAA03903 for kermit.misc@watsun; Fri, 27 Dec 1996 13:49:45 -0500 (EST)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Not really a kermit question
  8. Date: 27 Dec 1996 18:48:45 GMT
  9. Organization: Columbia University
  10. Lines: 90
  11. Message-ID: <5a15md$8gs$1@apakabar.cc.columbia.edu>
  12. References: <5a119e$c6f@news1.voicenet.com>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:6326
  15.  
  16. In article <5a119e$c6f@news1.voicenet.com>,
  17. Christopher Mosley <cmosley@voicenet.com> wrote:
  18. : I noticed that I had poor throughput during most of my sessions.
  19. : I tested this using mskermit and ckermit by using up/downloads during
  20. : serial dialin sessions. This is what I discovered:
  21. :  28.8 connection 115200 modem speed, windows 5, packet size 5000,
  22. :  42.bis compression,rts/cts. 
  23. As you might know, you can also squeeze another 20-25% throughput when
  24. transferring binary and/or precompressed files by using control-character
  25. prefixing (available in C-Kermit 5A(189) or later, MS-DOS Kermit 3.13 or
  26. later -- the current versions are 6.0.192 and 3.14, respectively).
  27.  
  28. :  1. A session fell into one of two categories either a throughput of
  29. :  3500 - 3900 cps or 6000 - 6500 cps for a text file (always the same file).
  30. :  The througput for a precompessed file was always ~3200 cps - this
  31. :  to assure that that varying line conditions did not account for the
  32. :  disparity. ~3200 was also the rate for a non-compressed session for
  33. :  any kind of file. During any one dial in session the cps did not change 
  34. :  from the slower realm to the faster or faster to slower.
  35. :  
  36. OK, so 3200 cps for a precompressed file, always.  That indicates, roughly,
  37. the actual capacity of the connection.  This is almost exactly what is
  38. expected (2880 cps / 8-bits-per-character = 3600 cps less about 11% LAPM
  39. (V.42) overhead = 3204 cps).   And the constancy of this figure rules out
  40. modulation downshifting of the V.34 connection.  So far so good.
  41.  
  42. Now a text file is usually quite compressible.  The degree to which it
  43. is compressed prior to transfer, then, all else being equal (and it seems
  44. to be) determines the throughput.
  45.  
  46. If sometimes the file transfers at 3500-3900 cps, and others at 6000-6500,
  47. this indicates that the the modems have successfuly negotiated a compression
  48. protocol in the latter case, but not in the former.  This can be verified
  49. by setting your modem to display its active protocols when it gives its
  50. CONNECT message, or by escaping back to the modem after connection and giving
  51. the appropriate command for displaying protocols.
  52.  
  53. :  2. Varing packet-lengths had no effect other than to slow or speed
  54. :  up everythimg by the expected amount.
  55. :  3.These results were basicly the same at all times: the likelyhood   
  56. :  of having a good or bad session was the same,  1 out of every 5 
  57. :  sessions was 'a good one'. This was during times of heavy or light
  58. :  load on the remote. It was possible to have a good session at times
  59. :  when the load on the remote was the heaviest and to have a bad
  60. :  session when the the lightest.
  61. :  4. The results were about the same for mnp compression.
  62. :  What I wonder.
  63. :  1.It seems that compression is occuring, but what is this 
  64. :  partial compression! ;-( , 3800cps for a file a file that would
  65. :  have a transfer rate of only slightly less (3200 cps)
  66. :  when a compression free connection was made?
  67. :      
  68. That's because Kermit protocol includes its own form of compression that
  69. is independent of the modem's.
  70.  
  71. : The reason I am posting here is the responses/suggestions I have gotten are:
  72. :   Don't use kermit. ?
  73. :
  74. Thanks for not listening to that one.  I think if you ran the same
  75. experiments with ZMODEM (which is, no doubt, what these people would tell
  76. you to use), you would get the same results for precompressed files, but you
  77. would probably get only the expected 3200 cps for text files, rather than
  78. the higher throughput that you got with Kermit.  That's assuming the clean
  79. and totally transparent kind of connection that is required for ZMODEM to
  80. work well, or at all.
  81.  
  82. :   Shouldn't use packet lengths of over 1024 on a hayes compatible modems. ?  
  83. That doesn't make any sense.  It's not the brand name or command set of the
  84. modem that's important, but rather its buffering and flow-control capacity.
  85. In general, the improvement from packet lengths over 1000 is marginal, but
  86. sometimes (almost in defiance of the underlying math) it can be significant.
  87. More often, a larger window size is more beneficial.  In all cases, of
  88. course, you can also improve throughput by "unprefixing" those control
  89. characters that are safe to send bare.
  90.  
  91. Kermit performance is discussed and analyzed in depth, with particular
  92. reference to V.34 connections, in Chapter 12 of the new second edition of
  93. "Using C-Kermit":
  94.  
  95.   http://www.columbia.edu/kermit/ck60manual.html
  96.  
  97. - Frank